% THIS IS SIGPROC-SP.TEX - VERSION 3.1
% WORKS WITH V3.2SP OF ACM_PROC_ARTICLE-SP.CLS
% APRIL 2009
%
% It is an example file showing how to use the 'acm_proc_article-sp.cls' V3.2SP
% LaTeX2e document class file for Conference Proceedings submissions.
% ----------------------------------------------------------------------------------------------------------------
% This .tex file (and associated .cls V3.2SP) *DOES NOT* produce:
%       1) The Permission Statement
%       2) The Conference (location) Info information
%       3) The Copyright Line with ACM data
%       4) Page numbering
% ---------------------------------------------------------------------------------------------------------------
% It is an example which *does* use the .bib file (from which the .bbl file
% is produced).
% REMEMBER HOWEVER: After having produced the .bbl file,
% and prior to final submission,
% you need to 'insert'  your .bbl file into your source .tex file so as to provide
% ONE 'self-contained' source file.
%
% Questions regarding SIGS should be sent to
% Adrienne Griscti ---> griscti@acm.org
%
% Questions/suggestions regarding the guidelines, .tex and .cls files, etc. to
% Gerald Murray ---> murray@hq.acm.org
%
% For tracking purposes - this is V3.1SP - APRIL 2009

\documentclass{acm_proc_article-sp}
\usepackage{pdfpages}

\begin{document}

\title{Exploring OS Fingerprinting}
%%\subtitle{[Extended Abstract]
%%\titlenote{A full version of this paper is available as
%%\textit{Author's Guide to Preparing ACM SIG Proceedings Using
%%\LaTeX$2_\epsilon$\ and BibTeX} at
%%\texttt{www.acm.org/eaddress.htm}}}
%
% You need the command \numberofauthors to handle the 'placement
% and alignment' of the authors beneath the title.
%
% For aesthetic reasons, we recommend 'three authors at a time'
% i.e. three 'name/affiliation blocks' be placed beneath the title.
%
% NOTE: You are NOT restricted in how many 'rows' of
% "name/affiliations" may appear. We just ask that you restrict
% the number of 'columns' to three.
%
% Because of the available 'opening page real-estate'
% we ask you to refrain from putting more than six authors
% (two rows with three columns) beneath the article title.
% More than six makes the first-page appear very cluttered indeed.
%
% Use the \alignauthor commands to handle the names
% and affiliations for an 'aesthetic maximum' of six authors.
% Add names, affiliations, addresses for
% the seventh etc. author(s) as the argument for the
% \additionalauthors command.
% These 'additional authors' will be output/set for you
% without further effort on your part as the last section in
% the body of your article BEFORE References or any Appendices.

\numberofauthors{2} %  in this sample file, there are a *total*
% of EIGHT authors. SIX appear on the 'first-page' (for formatting
% reasons) and the remaining two appear in the \additionalauthors section.
%
\author{
% You can go ahead and credit any number of authors here,
% e.g. one 'row of three' or two rows (consisting of one row of three
% and a second row of one, two or three).
%
% The command \alignauthor (no curly braces needed) should
% precede each author name, affiliation/snail-mail address and
% e-mail address. Additionally, tag each line of
% affiliation/address with \affaddr, and tag the
% e-mail address with \email.
%
% 1st. author
\alignauthor
Marcus Pendleton\\%\titlenote{Dr.~Trovato insisted his name be first.}\\
       \affaddr{The University of Texas at San Antonio}\\
       \affaddr{1 UTSA Circle}\\
       \affaddr{San Antonio, Texas 78249}\\
       \email{marcusp46@yahoo.com}
% 2nd. author
\alignauthor
Temitope Ajagbe\\%\titlenote{The secretary disavows
%any knowledge of this author's actions.}\\
       \affaddr{The University of Texas at San Antonio}\\
       \affaddr{1 UTSA Circle}\\
       \affaddr{San Antonio, Texas 78249}\\
       \email{temitopeajagbe@gmail.com}
% 3rd. author
%\alignauthor Lars Th{\o}rv{\"a}ld\titlenote{This author is the
%one who did all the really hard work.}\\
%       \affaddr{The Th{\o}rv{\"a}ld Group}\\
%       \affaddr{1 Th{\o}rv{\"a}ld Circle}\\
%       \affaddr{Hekla, Iceland}\\
%       \email{larst@affiliation.org}
%\and  % use '\and' if you need 'another row' of author names
% 4th. author
%\alignauthor Lawrence P. Leipuner\\
%       \affaddr{Brookhaven Laboratories}\\
%       \affaddr{Brookhaven National Lab}\\
%       \affaddr{P.O. Box 5000}\\
%       \email{lleipuner@researchlabs.org}
% 5th. author
%\alignauthor Sean Fogarty\\
%       \affaddr{NASA Ames Research Center}\\
%       \affaddr{Moffett Field}\\
%       \affaddr{California 94035}\\
%       \email{fogartys@amesres.org}
% 6th. author
%\alignauthor Charles Palmer\\
%       \affaddr{Palmer Research Laboratories}\\
%       \affaddr{8600 Datapoint Drive}\\
%       \affaddr{San Antonio, Texas 78229}\\
%       \email{cpalmer@prl.com}
}
% There's nothing stopping you putting the seventh, eighth, etc.
% author on the opening page (as the 'third row') but we ask,
% for aesthetic reasons that you place these 'additional authors'
% in the \additional authors block, viz.
%\additionalauthors{Additional authors: John Smith (The Th{\o}rv{\"a}ld Group,
%email: {\texttt{jsmith@affiliation.org}}) and Julius P.~Kumquat
%(The Kumquat Consortium, email: {\texttt{jpkumquat@consortium.net}}).}
\date{16 December 2013}
% Just remember to make sure that the TOTAL number of authors
% is the number that will appear on the first page PLUS the
% number that will appear in the \additionalauthors section.

\maketitle
\nocite{*}
\begin{abstract}
In military strategy, opposing forces often survey the enemy order of battle (EOB) of each 
other to determine the strategy that should be used in an attack or defense.  The same holds 
true for attackers in cyberspace.  In order for attackers to be successful with a high 
probability and few iterations, they need to know which vulnerabilities afflict the systems 
they are targeting.  As the operating system (OS) is the first software component of a system
interacted with by packets through their network stacks, it makes sense to determine the 
specific OS and version running on the other end in order to select which malicious tools to 
employ for subversion.  This effort is generally known as OS fingerprinting, and there are 
several techniques which comprise this area.  Generally speaking, exploiting design shortcomings 
of  TCP/IP or datagram protocols and also incorrect or incomplete compliance to RFC standards are 
what helps attackers identify systems and why OS fingerprinting remains so successful.  In this 
project, we explore the two major OS fingerprinting approaches: the TCP/IP stack and ICMP behaviors.
\end{abstract}

% A category with the (minimum) three required fields
%\category{H.4}{Information Systems Applications}{Miscellaneous}
%A category including the fourth, optional field follows...
%\category{D.2.8}{Software Engineering}{Metrics}[complexity measures, performance measures]

%\terms{Theory}

%\keywords{ACM proceedings, \LaTeX, text tagging} % NOT required for Proceedings

\section{Introduction}
As you can imagine, when an attacker targets a system, typically she would like to do so in a 
stealthily manner, using as few steps as possible to subvert a system.  Fewer steps reduces the 
likelihood that an administrator or intrusion detection/prevention system will raise any alerts 
to abnormal activity.  Therefore, it makes sense that if an attacker wishes to target a computer 
system, she would like to know which tools to use for a high probability hit.  Rather than enumerate 
through all the exploits an attacker might have in her toolbox,  which will mostly fail because 
they do not match the vulnerabilities of a target, it makes sense to gather information about the 
target and then select an appropriate tool for the subversion.  This is the fundamental idea of OS
fingerprinting, where an attacker wishes to know more about the target before an attack.  Although we 
introduce this technique as something used by an attacker, it may also the case that OS fingerprinting might
be used for legitimate purposes where an network administrator might need to know details about a 
machine on the other end of a network for troubleshooting.  This is fairly easy to accomplish because 
the OS is the entity that handles the network stack which implements the various protocols on a networks 
and they do so with slight differences due to incorrect or incomplete implementations, or variances on 
their compliance with Request For Comments(RFC) standards.  There are two general approaches for 
fingerprinting an OS using solely its network stack: TCP/IP and ICMP.  These are explained in detail 
this their respective subsections.

\subsection{TCP/IP Fingerprinting}
While many Operating Systems out there base their TCP stack on the old BSD release, there have been
so many changes made that there are now pretty significant differences between all of the main Operating
Systems.As critical bugs come out, vendors issue patches to their TCP stacks.Vendors tweak the stacks
between releases, usually to improve them.These differences and nuances in implementation over time
has become a good indicator of the operating systems running on a host device.	

\subsection{ICMP Fingerprinting}
TCP/IP is considered the old and conventional method of determining the OS of a target system remotely.
After the cyber community became aware that malicious users can utilize this to tailor subsequent 
attacks to a target, the community responded by developing more secure firewall and intrusion detection 
rules.  As TCP/IP fingerprinting requires that the remote target have a listening port, obscuring systems 
behind a firewall and closing unnecessary ports on a host limits the success of this method.  To circumvent 
this limitation, hacker communities have researched fingerprinting an OS using the ubiquitous ICMP protocol, 
which is used for various network and host control messages, and basic services such as timestamps.  According 
to Arkin, they have found that this method is very successful, being able to determine the OS of a target with 
as few as 1 packet, and typically up to 4 on the higher end.  Like TCP/IP, they attribute the ability to 
fingerprint an OS due to incorrect or incomplete implementations, and lack of compliance to updated RFC 
standards.  A partial list of the test cases used to dinguish between vari.

\section{Strategy}
Because we were unsure of the degree of success we would encounter with either TCP/IP or ICMP fingerprinting 
of the various OSs under consideration, we decided to explore both protocols and compile our results, which 
can be used for a more complete fingerprint of each OS.  In reality, typically one or the other stack would be 
exploited as they offer pros and cons orthogonal to each other.  For both protocols, we use hping3 for packet 
construction and analysis.  This was not only a project requirement, but this saves us from having to implement 
our own tool for raw packet construction and dumping.  Because fingerprinting using the two protocols can be 
investigated independently, we used two different platforms to explore fingerprinting using the two approaches.  
The test platforms used for each direction are detailed in their respective sections in this chapter.

\subsection{TCP/IP Strategy}
Any device on the network can be scanned either for identification in everyday business usage or surveillance scenario. From printer, router , bridges , fax , copiers , servers e.t.c. TCP IP scan attempts to identify an unknown hosts by operating systems using correlation in  behavior of the TCP IP stack in response to crafted IP packets.This rely on the assumption that operating systems vary greatly in the order that they return TCP options.This requires open ports (TCP and UDP) hence may consume network bandwidth and CPU.

A baseline of fingerprints or known behaviors must be established to properly analyze or cluster the target hosts within the limits or tolerance desired.

Three steps involved are
\begin{enumerate}
\item Send a packet to an open port on the host
\item Analyze the response
\item Compare response with known profile
\end{enumerate}
This papers tested patterns of responses to initial sequence numbers for Ubuntu , FreeBSD , OpenBSD and Windows. These operating systems. 

\subsection{ICMP Strategy}
Due to time constraint and lack of background in ICMP fingerprinting, it was decided to utilize similar resources that a hacker might use to develop an ICMP fingerprinting tool. We structured our development and testing environment similar to Ofir Arkin’s and Fyodor Yarochkin’s article titled ICMP based remote OS TCP/IP stack fingerprinting techniques published on the popular hacking magazine Phrack. The development and test platform is structured similar to above.  However, the OSs under investigation are different.  The list of OSs used for development and testing ICMP fingerprinting are as follows
\begin{itemize}
\item FreeBSD 9
\item Oracle Solaris 11.1
\item Microsoft Windows XP
\item Linux 3.10
\end{itemize}

The overall goal is to use Arkin's guide to enumerate through as many test cases needed to distinguish between the OSs in this sample rather than going through each in detail.  This is just to demonstrate the process of collection and using behavioral differences to identify an OS.  For a real tool, many OSs would need to be tested for a more complete database of responses to  distinguish between OSs in similar families, such as MacOS and FreeBSD, as the former based many of its higher level OS functionality on the code base of the latter.  In other words, a larger sample will result in a better tool.  The testcases needed to identify each OS from our small set will be outlined in the results section.

\section{Implementations}
TCP/IP and ICMP fingerprinting methodologies were explored in parallel.  Please refer to the respecive sections regarding implementation details.

\subsection{TCP/IP Fingerprinting Implementation}
10 packets were sent to the same operating system with the same initial sequence number. A total of 1000 sequence numbers were used per operating system. The number was arbitrary but provided a good number for analysis. After capturing the data, average returned sequence number was computed and \\
\texttt{
\#! /bin/bash\\
\#\\
\#    Bash script to capture the sequence numbers in analysis\\
\#    -------------------------------------------------------\\
\#    Ubuntu        FreeBsd    OpenBSD    Windows\\
declare -a iplist=('192.168.1.1' '206.190.36.45' '198.138.253.109' );\\
echo \char36\char123iplist[0]\char125;\\
\#\#Get number of ip addresses\\
ipCount=\char123\#iplist[@]\char125;\\
for (( ip=0;ip< ipCount;ip++ )) \\
\# process each IP address\\
do\\
   echo "Processing IP " \char36\char123iplist[ip]\char125\\
   for ((i=0;i<1;i++))\\
   do \\
     for (( sqnm=1;sqnm<2;sqnm++))\\
     do\\
        sudo `nping -tcp -p 80 -c 10 -seq=\char36sqnm \char36\char123iplist[ip]\char125 > \char36\char123iplist[ip]\char125".txt"`\\
     done\\
   done  \\
done\\}	

\subsection{ICMP Fingerprinting Implementation}
The packet construction and dumping tool was already provided by hping3.  Because this tool dumps readable characters to the screen, and we needed to make binary comparisons and computations for some tests, we developed icmp\_checksum to read the dumped packets written to standard output (stdout) in hexadecimal format and convert them into our own decoded packet structures which stored fields in a format more representable of their binary form in a packet.  This tool was especially useful for recomputing the checksum of packets, which is a feature used to distinguish between OSs as some do not compute them correctly.  The source of our program can be review in attachments.  The main command line usage pipes output from the hping3 program to input of our program:

\texttt{hping3 -j --icmp 192.168.1.13  --count 1 | ./icmp\_checksum}

The example command line usage pipes the hex dump of the full IP packet including the ICMP data (-j), sends a ping packet to the displayed IP address, and stops after receiving 1 packet (--count 1).  There are no switches necessary for icmp\_check as it just simply displays the numerical fields of the IP header in full.

%\begin{figure}
%\centeringtable
%\psfig{file=rosette.ps, height=1in, width=1in,}
%\caption{A sample black and white graphic (.ps format) that has
%been resized with the \texttt{psfig} command.}
%\end{figure}

%\begin{figure*}
%\centering
%\epsfig{file=flies.eps}
%\caption{A sample black and white graphic (.eps format)
%that needs to span two columns of text.}
%\end{figure*}
%and don't forget to end the environment with
%{figure*}, not {figure}!
\section{Results}
Mixed results were obtained in TCP/IP and ICMP fingerprinting.  Please refer to the respective sections for the outcomes of the various test employed in those areas.

\subsection{TCP/IP Fingerprinting Results}
 	
\begin{tabular}{|l | c |}
  \hline
  OS & Distribution of Initial Sequence Number \\ \hline
  Ubuntu Linux & Time dependent linear distribution \\ \hline
  FreeBSD & Clustered \\ \hline
  OpenBSD 11.1 & clustered but uniquely shaped \\ \hline
  Windows XP 9 & Even spread\\ \hline
\end{tabular}

\subsection{ICMP Fingerprinting Results}
Only moderate success was met with ICMP fingerprinting.  Out of the test cases provideded by Arkin, only a couple helped to distinguish between the OSs in our sample.  We believe that because the article by Arkin was written in 2001, and because their techniques relied on incorrect and incomplete implementations on OSs available then, that current OSs have corrected these behaviors.  The main attributes that helped us distinguishes the OSs in our sample included:
\begin{itemize}
\item A1- IP Flags
\item A2- Time-to-Live (TTL)
\item A3- IP Total Length
\item A4- ICMP code echo
\item A5- Timestamp service
\end{itemize}

Attribute A1 refers to the flags that must be set according to RFC 792 in an RFC echo reply message.  The standard is that the flags set in the request message should also be set in the reply message.  In the case of Solaris, it set the Do-Not-Frag bit despite being sent a request with it cleared.  For A2, it appears that vendors have freedom to set the TTL to a value of their choice.  All seem to be reasonable values, considering the fact that it is hard to imagine 64 nodes between two end-points.  However, we can use the arbitrary values set by the vendors as a distinguishing feature.  A3 refers to the test case where IP Total Length is miscalculated by some vendors.  We found this to be true with Windows and Solaris, as it added an extra 18 bytes to the total length of a standard echo reply message.  The 18 extra bytes was confirmed to be erroneous as we found not essential data in the padded area, where the bytes were all 0.  In attribute A4, RFC 792 mandates that the code value set after the type field must be the same value in the reply message.  In the case of Windows, it alwys reset the code value to 0, which is the value of most request messages anyway.  However, the remaining OSs complied with the RFC, so we used this as a feature to help identify Windows OSs from the pool.  Finally, A5 refers to the timestamp service defined in RFC 792.  By default, the OSs returned timestamp replies except Solaris.  It appears that the default setting for Solaris is to disable timestamp requests.  This is probably in response to vendor's awareness that this is used to fingerprint OSs.  A table summarizing these attributes follows below.\\

\begin{tabular}{l | c c c c c}
  OS & Attr1 & Attr2 & Attr3 & Attr4 & Attr5 \\ \hline
  Windows XP & Std & 128 & 46 & Non-Std & A\\
  Linux 3.10 & Std & 64 & 28 & Std & A\\
  Solaris 11.1 & Non-Std & 255 & 46 & Std & N/A \\
  FreeBSD 9 & Std & 64 & 28 & Std & A\\
\end{tabular}

If we were to consider each row as a tuple, we could use that as a signature to identify an OS.  In our case, we have two rows that are identical: Linux and FreeBSD.  This means that further test cases are required to help distinguish between the remaining OSs.  Ideally, a database of all OSs would be compiled with a signature for each OS as in reality, using fewer features will only help you identify families of OSs at best.

\section{Conclusions}
TCP/IP fingerprinting is effective at identify hosts with known open ports and generally provides a clustered SYN-ACK sequence numbers around a central mean for a given operating system. Hence, this is effective at identifying a host in reconnaissance.It is required that port scan be conducted to identify open ports. Closed ports will not accept connection hence will not return any useful information for analysis hence if there are no open ports, this approach will fail.

With regards to the ICMP fingerprinting, it was possible to immediately see differentiating features between OS’s from a simple ping request.  We suspect that following the remainder of test cases enumerator by Arkin and Yarochkin that a more comprehensive database can be constructed detailing the peculiarities that distinguish the many OSs in existence on the Internet.  With the added quality of needing few packets to positively identify an OS and the ability to traverser firewalls and IDSs, this might be considered the more powerful of the two techniques.
%\end{document}  % This is where a 'short' article might terminate

%ACKNOWLEDGMENTS are optional
%\section{Acknowledgments}
%This section is optional; it is a location for you
%to acknowledge grants, funding, editing assistance and
%what have you.  In the present case, for example, the
%authors would like to thank Gerald Murray of ACM for
%his help in codifying this \textit{Author's Guide}
%and the \textbf{.cls} and \textbf{.tex} files that it describes.

%
% The following two commands are all you need in the
% initial runs of your .tex file to
% produce the bibliography for the citations in your paper.
\bibliographystyle{abbrv}
\bibliography{sigproc}  % sigproc.bib is the name of the Bibliography in this case
% You must have a proper ".bib" file
%  and remember to run:
% latex bibtex latex latex
% to resolve all references
%
% ACM needs 'a single self-contained file'!
%
%APPENDICES are optional
%\balancecolumns
%\appendix
%Appendix A
%\section{Headings in Appendices}
%The rules about hierarchical headings discussed above for
%the body of the article are different in the appendices.
%In the \textbf{appendix} environment, the command
%\textbf{section} is used to
%indicate the start of each Appendix, with alphabetic order
%designation (i.e. the first is A, the second B, etc.) and
%a title (if you include one).  So, if you need
%hierarchical structure
%\textit{within} an Appendix, start with \textbf{subsection} as the
%highest level. Here is an outline of the body of this
%document in Appendix-appropriate form:
%\subsection{Introduction}
%\subsection{The Body of the Paper}
%\subsubsection{Type Changes and  Special Characters}
%\subsubsection{Math Equations}
%\paragraph{Inline (In-text) Equations}
%\paragraph{Display Equations}
%\subsubsection{Citations}
%\subsubsection{Tables}
%\subsubsection{Figures}
%\subsubsection{Theorem-like Constructs}
%\subsubsection*{A Caveat for the \TeX\ Expert}
%\subsection{Conclusions}
%\subsection{Acknowledgments}
%\subsection{Additional Authors}
%This section is inserted by \LaTeX; you do not insert it.
%You just add the names and information in the
%\texttt{{\char'134}additionalauthors} command at the start
%of the document.
%\subsection{References}
%Generated by bibtex from your ~.bib file.  Run latex,
%then bibtex, then latex twice (to resolve references)
%to create the ~.bbl file.  Insert that ~.bbl file into
%the .tex source file and comment out
%the command \texttt{{\char'134}thebibliography}.
% This next section command marks the start of
% Appendix B, and does not continue the present hierarchy
%\section{More Help for the Hardy}
%The acm\_proc\_article-sp document class file itself is chock-full of succinct
%and helpful comments.  If you consider yourself a moderately
%experienced to expert user of \LaTeX, you may find reading
%it useful but please remember not to change it.
\balancecolumns
% That's all folks!
\includepdf[pages=-]{icmp_checksum}
\end{document}
